Clarified:-
The main case in mind is that the account check is able to test the contents of an account after an instruction in a series of instructions, but it cannot perform checks that require the resulting state of several accounts simultaneously after the particular instruction has been run, an example would be an AMM, where the amounts in the vaults after a swap would all be tested to together to satisfy some equation, which would result after a swap or similar instruction in a series of instructions has just been run.

Clarified:- The main case in mind is that the account check is able to test the contents of an account after an instruction in a series of instructions, but it cannot perform checks that require the resulting state of several accounts simultaneously after the particular instruction has been run, an example would be an AMM, where the amounts in the vaults after a swap would all be tested to together to satisfy some equation, which would result after a swap or similar instruction in a series of instructions has just been run.

I think for a situation like this, you actually want to just access the returned InstructionResult directly. It has its own API for retrieving resulting accounts and you can just use assert!/assert_eq! on the data, or use result.run_checks.

I'm worried that getting into the weeds here on generic checks might set a bad precedent for the API's development. It's really hard to try to write a good generic check parameter like this that's expansive enough to cover all of the edge cases someone might have. In fact, that's exactly what the API on the InstructionResult was for in the first place.